Safety Contracts for Timed Reactive Components in SysML

A variety of system design and architecture description languages, such as SysML, UML or AADL, allows the decomposition of complex system designs into communicating timed components. In this paper we consider the contract-based specification of such components. A contract is a pair formed of an assumption, which is an abstraction of the component’s environment, and a guarantee, which is an abstraction of the component’s behavior given that the environment behaves according to the assumption. Thus, a contract concentrates on a specific aspect of the component’s functionality and on a subset of its interface, which makes it relatively simpler to specify. Contracts may be used as an aid for hierarchical decomposition during design or for verification of properties of composites. This paper defines contracts for components formalized as a variant of timed input/output automata, introduces compositional results allowing to reason with contracts and shows how contracts can be used in a high-level modeling language (SysML) for specification and verification, based on an example extracted from a real-life system. 1 Motivation and Approach The development of safety critical real-time embedded systems is a complex and costly process, and the early validation of design models is of paramount importance for satisfying qualification requirements, reducing overall costs and increasing quality. Design models are validated using a variety of techniques, including design reviews [24], simulation and model-checking [19, 25]. In all these activities system requirements play a central role; for this reason processes-oriented standards such as the DO-178C [22] emphasize the necessity to model requirements at various levels of abstraction and ensure their traceability from high-level down to detailed design and coding. Since the vast majority of systems are designed with a component-based approach, the mapping of requirements is often difficult: a requirement is in general satisfied by the collaboration of a set of components and each component is involved in satisfying several requirements. A way to tackle this problem is to have partial and abstract component specifications which concentrate on specifying how a particular component collaborates in realizing a particular requirement; such a specification is called a contract. A contract is defined as a pair formed of an assumption, which is an abstraction of the component’s environment, and a guarantee, which is an abstraction of the component’s behavior given that the environment behaves according to the assumption. The justification for using contracts is therefore manyfold: support for requirement specification and decomposition, mapping and tracing requirements to components and even for model reviews. Last but not least, contracts can support formal verification of properties through model-checking. Given the right composability properties, they can be used to restructure the verification of a property by splitting it in two steps: (1) verify that each component satisfies its contract and (2) verify that the network of contracts correctly assembles and satisfies the property. Thus, one only needs to reason on abstractions when verifying a property, which potentially induces an important reduction of the combinatorial explosion problem. Our interest in contracts is driven by potential applications in system engineering using SysML [23], in particular in the verification of complex industrialscale designs for which we have reached the limits of our tools [16]. In SysML one can describe various types of communicating timed reactive components; for most of these, their semantics can be given in a variant of Timed Input/Output Automata (TIOA) [21]. For this reason, in this paper we concentrate on defining a contract theory for TIOA. This contract theory is applied on a SysML case study extracted from real-life. 2 A Meta-Theory for Contract-based Reasoning Our contract theory is an instance of the meta-theory proposed in [27] and later detailed in [26], which formalizes the relations that come into play in a contract theory and the properties that these relations have to satisfy in order to support reasoning with contracts. The term meta-theory refers to the fact that the formalism used for component specification is not fixed, nor the exact nature of certain relations defined on specifications (conformance, refinement under context). In order to obtain a concrete contract theory for a particular specification formalism one has to define these relations such that certain properties, prerequired by the meta-theory, are satisfied. In return, this meta-theory provides a ready-to-use contract-based methodology. The purpose of this methodology is to support reasoning with contracts in a system obtained by hierarchical composition of components. At any level of the hierarchy, n componentsK1, ...,Kn are combined to form a composite component K1 ‖ ... ‖ Kn, where ‖ denotes the parallel composition operator. Then verifying that the composite satisfies a global property φ runs down to checking that the contracts implemented by K1, ...,Kn combine together correctly to ensure φ. This avoids the need to directly model-check the composite to establish φ and, so, alleviates the combinatorial explosion of the state space. The contracts being specified by more abstract automata, one can assume that their composition will be reduced. The reasoning proceeds as follows: for each component Ki, a contract Ci is given which consists of an abstraction Ai of the behavior of Ki’s environment, and an abstraction Gi that describes the expected behavior of Ki given that the environment acts as Ai. Fig. 1 presents three components K1, K2 and K3 and a corresponding set of contracts C1, respectively C2 and C3. Step 1 of the reasoning consists in verifying that each component is a correct implementation of the contract, i.e. the component satisfies its contract. The satisfaction relation is directly derived from a more general one named refinement under context. The purpose of the latter is to model that a component Ki is a correct refinement of the specificationKj in the given environment Ek. Thus, a component implements